home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000477_connolly@pixel.convex.com _Thu Dec 10 18:51:45 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA06362; Thu, 10 Dec 92 18:51:45 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA09487; Thu, 10 Dec 1992 19:05:10 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA15908; Thu, 10 Dec 92 12:05:04 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA05022; Thu, 10 Dec 92 12:05:02 -0600
  10. Message-Id: <9212101805.AA05022@pixel.convex.com>
  11. To: Guido.van.Rossum@cwi.nl
  12. Cc: www-talk@nxoc01.cern.ch
  13. Subject: Re: Gopher+ Considered Harmful 
  14. In-Reply-To: Your message of "Thu, 10 Dec 92 10:55:24 +0100."
  15.              <9212100955.AA26659.guido@voorn.cwi.nl> 
  16. Date: Thu, 10 Dec 92 12:05:02 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >I once explained the current HTTP protocol to a local network guru and
  21. >he expressed concern that basing a protocol like this on TCP/IP is a
  22. >great waste of network resources, since you are using a
  23. >session-oriented protocol for what is essentially one remote procedure
  24. >call.
  25.  
  26. Do the WAIS folks know about this? I wonder what they'd say...
  27.  
  28. >  My question "then what would you recommend instead" provoked no
  29. >useful answer (what is needed is *reliable* datagrams, but these are
  30. >not implemented as an IP protocol; UDP requires too much coding for
  31. >time-out, retransmission and fragmentation).  Yet, he convinced me
  32. >that a light-weight protocol like this should minimize the number of
  33. >round-trips.
  34.  
  35. I agree.
  36.  
  37. >I have the feeling that the current trend of basing the new protocol
  38. >on NNTP violates that requirement.  I like the idea of borrowing
  39. >response and data formats from the FTP/SMTP/NNTP family of protocols,
  40. >with suitable extensions for 8-bit data paths.  However I don't like
  41. >it if compatibility with NNTP forces us to have an extra round trip
  42. >just so that the server can give its welcome message.
  43.  
  44. The idea was to use the existing usenet distributed database. But
  45. I guess we should just use plain old NNTP for that.
  46.  
  47. >Also, I don't like the fact that you must parse the RFC822/MIME header
  48. >to find out how many bytes are to be expected.  This seems to be
  49. >mixing two levels of protocols: MIME assumes that the end of the
  50. >message is already known, and the MIME headers then tell you what to
  51. >do with it.
  52.  
  53. I certainly didn't think it out very carefully, did I?
  54.  
  55. >As I see it, there are two possible ways of using MIME in HTTP+.  We
  56. >can either support MIME as the *only* data format (implementing any
  57. >extensions we need as new MIME content types or subtypes or additional
  58. >headers), or we we support MIME as one of the possible data formats.
  59.  
  60. A terminology note here: there is no one "MIME data format." There's
  61. the ubiquitous message/rfc822 format that you can stick anything
  62. inside using MIME techniques. But the basic unit of information
  63. in the MIME spec is an _entity_ -- just an arbitrary stream of bytes.
  64.  
  65. The question is, when you're sending an entity from one
  66. place to another, how do you know where the end is?